Developers of databases provide customers the ability to manage their respective databases. This ability to manage is enabled through management software (including user interfaces) that allows a customer (or, more specifically, a database administrator (DBA)) to interact with a database, view how the database is performing, and take actions to alleviate problems and plan for contingencies. Such database management software may allow a DBA to generate a report that indicates different performance metrics associated with one or more databases of an enterprise. Example performance metrics may include CPU utilization, memory utilization, network utilization, number and types of queries in one or more workloads, etc. A DBA may use a report to determine that performance has degraded and to identify what is causing the performance degradation.
Many times, a DBA is unable to identify a source or cause of a database problem, whether through lack of sufficient training or complexity of the database problem. In such situations, the DBA may rely on experts of the database involved to help resolve the database problem. However, those experts typically do not have access to the database. In other words, the experts are “offline” relative to the database.
One possible approach to address this offline problem is for the DBA to generate a report, cause the report to be displayed on a computer screen, take a screenshot of the screen, save the screenshot to a particular location (e.g., folder) on the DBA's computer, open up an email application, compose a new email message, attach the saved screenshot to the new email message, and send the message to an expert. Clearly, such an approach requires many manual steps. Furthermore, the expert only has access to a single screenshot. Many times, an expert needs to be able to view additional data that is not displayed in the screenshot. For example, an expert may need to reorganize a list, adjust a slider to view additional data, or click on a link to another (related) report in order to determine the cause of a database problem. With a screenshot, none of these options is possible.
One way to address this problem is for the DBA to generate numerous reports, take screenshots of each report, and send the screenshots to an expert. However, such an approach does not address the problem of the DBA having to perform many manual steps. Also, the DBA does not know ahead of time which report will be most useful to the expert. Thus, the DBA may take numerous screenshots that will never be used by the expert. Also, for some reports, the number of possible views within a single report (e.g., number of tabs or ways in which a list may be reordered) may be significant, requiring the DBA to take several (potentially useless) screenshots.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.